Dragonfly cumple tres anios como alternativa compatible con el protocolo de Redis, y en 2025 ya se puede hablar de ella con datos en mano y no solo con los anuncios del lanzamiento. La conversacion ha cambiado: hace dos anios la pregunta era si iba a sobrevivir al empuje de Redis, y ahora la pregunta es si tiene sentido desplegarlo de serie para ciertos patrones. En este post cuento que ha cambiado, donde encaja y donde sigue siendo prudente quedarse con lo conocido.
Lo que hace distinto a Dragonfly
Redis ha sido el referente durante mas de una decada, y su modelo de un solo hilo por nodo es intencional: evita bloqueos y simplifica el razonamiento sobre atomicidad. Dragonfly parte de ese mismo modelo de comandos y de la misma interfaz de red, pero por dentro es un sistema multihilo con arquitectura shared-nothing. Cada hilo gestiona su propio trozo de datos y la coordinacion entre hilos se hace mediante paso de mensajes, no mediante locks compartidos.
El efecto practico es que un nodo Dragonfly con ocho nucleos puede aprovechar los ocho, mientras que un nodo Redis tradicional solo usa uno y deja el resto del equipo ocioso. Para cargas ligeras eso no importa: un Redis sobrado aguanta decenas de miles de peticiones por segundo en un solo nucleo. Para cargas densas, con picos de cientos de miles de peticiones por segundo, Dragonfly permite mantener menos nodos, cada uno mejor aprovechado, a costa de una configuracion algo mas sensible al tamanio del equipo.
El otro gran cambio arquitectural es la forma de hacer snapshots. Redis clona el proceso con fork para volcar memoria a disco, lo cual funciona bien en equipos pequenios pero degrada la latencia cuando la memoria usada es grande, porque el sistema operativo tiene que duplicar paginas cuando cambian. Dragonfly implementa un algoritmo de snapshot propio que no depende de fork, con lo que la latencia se mantiene mientras se persiste. Esto parece un detalle, pero en cargas de varias decenas de gigabytes es la diferencia entre un pico visible de latencia cada pocos minutos y una linea plana.
Compatibilidad real con Redis
Dragonfly se anuncia como un reemplazo drop-in del protocolo de Redis, y en 2025 esa afirmacion es mucho mas solida que en 2022. Los comandos principales estan cubiertos, las estructuras de datos habituales funcionan, y la mayor parte de los clientes oficiales de Redis se conectan sin cambios. Yo he probado lectores de BullMQ, colas de Sidekiq y caches de aplicaciones PHP contra Dragonfly y el cambio fue transparente en los tres casos.
Donde aparecen los bordes es en funcionalidades menos centrales pero criticas para ciertos entornos. La replicacion con el protocolo nativo de Redis funciona pero con limitaciones en topologias complejas. Redis Streams estan soportados pero algunos consumidores muy especificos detectan diferencias sutiles. Las extensiones mediante modulos dinamicos, como RedisSearch o RedisJSON, no se cargan: Dragonfly implementa parte de esa funcionalidad de forma nativa, con su propio soporte para busqueda y JSON, pero con API ligeramente distinta. Si tu aplicacion depende de un modulo concreto, toca verificar con calma antes de migrar.
Casos donde compensa
Despues de ver varios despliegues, el patron donde Dragonfly se come a Redis es el cache denso. Un solo nodo Dragonfly con 128 gigabytes de memoria y dieciseis nucleos puede reemplazar un pequenio cluster de Redis con cuatro o seis nodos, simplificando la operacion y reduciendo el coste de infraestructura de forma apreciable. Para empresas que tienen Redis como capa de cache delante de una base de datos relacional, este tipo de consolidacion es el principal argumento.
El segundo caso es el de picos de trafico impredecibles. Con Redis tradicional, una subida repentina de escrituras puede saturar el unico hilo y generar colas. Con Dragonfly, la carga se reparte entre hilos y la degradacion es mas suave. Esto importa especialmente en comercios electronicos con campanias puntuales, en plataformas de medios con virales impredecibles o en APIs publicas con trafico irregular.
El tercer caso, menos obvio, es el de persistencia con estado grande. Si tu caso de uso requiere recargar millones de claves despues de un reinicio, la diferencia de velocidad en snapshots y recuperacion puede ahorrar minutos de indisponibilidad por despliegue, lo cual se nota en entornos con despliegues frecuentes.
Donde sigue siendo prudente quedarse con Redis
No todo son ventajas. Hay tres escenarios donde seguiria eligiendo Redis, o ahora Valkey, su fork dirigido por la Linux Foundation. El primero es cuando el equipo ya tiene experiencia profunda con Redis y herramientas internas construidas alrededor. Cambiar de motor por una ganancia marginal no compensa el coste de formacion y de reescribir scripts operativos.
El segundo es cuando la aplicacion depende de modulos como RedisSearch, RedisTimeSeries o RedisGraph en su version oficial. Aunque Dragonfly tenga equivalentes, la paridad funcional todavia no es total y hay diferencias de semantica que pueden morder en produccion.
El tercero, mas delicado, es el de los clientes empresariales que contratan soporte comercial directo. Redis Ltd. y ahora Valkey a traves de la Linux Foundation ofrecen canales de soporte maduros, con SLAs y con experiencia acumulada en despliegues complejos. Dragonfly tiene soporte comercial a traves de su empresa, Dragonfly Labs, pero el ecosistema de partners y la profundidad de la comunidad todavia no son comparables.
El factor Valkey en la ecuacion
Desde marzo de 2024, con el cambio de licencia de Redis a RSAL y SSPL y el nacimiento de Valkey bajo la Linux Foundation, la comparacion ya no es solo Dragonfly contra Redis. Valkey es un fork directo de Redis 7.2 con gobernanza abierta y licencia BSD, y en 2025 las grandes nubes publicas han ido migrando sus ofertas gestionadas hacia Valkey. Eso cambia el calculo: hoy la decision suele ser Dragonfly, Redis oficial o Valkey, y la respuesta depende mas del modelo de licencia que del rendimiento.
Mi lectura a dia de hoy es que, para despliegues nuevos donde no hay inercia, Dragonfly merece estar en la lista corta. Para despliegues existentes sobre Redis abierto, Valkey es el camino de menor friccion. Para despliegues existentes sobre versiones comerciales de Redis, la decision depende mas de la relacion con el proveedor que de un dato tecnico concreto.
Mi lectura
Dragonfly ha madurado hasta el punto de ser una opcion defendible y no un experimento. Su arquitectura multihilo encaja con cargas densas y con equipos modernos, y su algoritmo de snapshot sin fork resuelve un problema real que Redis arrastra desde su origen. Pero no es una bala de plata: el ecosistema de Redis, su comunidad y su soporte comercial siguen siendo ventajas reales que tardan en construirse.
La recomendacion practica es probarlo en un entorno de staging con una copia de trafico real antes de tomar decisiones definitivas. Las metricas de ahorro suelen ser llamativas, pero los bordes de compatibilidad solo aparecen cuando se prueba de verdad. Y en caches, los bordes raros son los que rompen produccion en un mal momento.
Por ahora, en jacar.es mantengo Redis 8 en la infraestructura principal por inercia y por el peso del ecosistema, pero estoy mirando con interes un servicio auxiliar donde la densidad de cache justifica probar Dragonfly en serio. Si esa prueba sale bien, igual esta conversacion cambia en los proximos meses.
